---
title: "Тестирование"
date: 2023-04-27T21:26:27+03:00
description: "Заметка о тестировании по мотиву видео от soer"
tags: ["test", "testing", "unit-testing", "e2e"]
ShowToc: true
ShowBreadCrumbs: true
draft: false
---

> На основе видео от soer: *Как писать тесты и не сойти с ума*

<iframe
    width="720"
    height="405"
    src="https://rutube.ru/play/embed/a3c419bdbf8eff9b843bcfc589c37e72" 
    frameBorder="0"
    allow="clipboard-write; autoplay"
    webkitAllowFullScreen
    mozallowfullscreen
    allowFullScreen>
</iframe>  

## Конспект

Необходимо рассматривать тесты через призму [регрессий](https://ru.wikipedia.org/wiki/Регрессионное_тестирование), а не доказательства корректности. То есть вместо того, чтобы писать все тесты на все кейсы надо сосредоточиться в первую очередь на тестах, которые проверяют функционал, который может сломаться при изменение. То есть нужно не тестировать все случаи, а только самые важные. Это подход позволит адаптировать команду к культуре написания тестов.

В плане покрытия тестами лучше сконцентрироваться на значении 80%, чем 100%.

Мартин Фаулер говорит о [покрытие тестами](https://martinfowler.com/bliki/TestCoverage.html) следующие:

> Like most aspects of programming, testing requires thoughtfulness. TDD is a very useful, but certainly not sufficient, tool to help you get good tests. If you are testing thoughtfully and well, I would expect a coverage percentage in the upper 80s or 90s. I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.

Перевод:

> Как и большинство аспектов программирования, тестирование требует вдумчивости. TDD — очень полезный, но, безусловно, недостаточный инструмент, который поможет вам получить хорошие тесты. Если вы тестируете вдумчиво и хорошо, я ожидаю, что процент покрытия будет выше 80 или 90%. Я бы с подозрением отнесся к чему-то вроде 100% — это бы пахло тем, что кто-то пишет тесты, чтобы осчастливить цифры покрытия, но не думает о том, что он делает.

[Хрупкие тесты](https://habr.com/ru/companies/skyeng/articles/659559/) — это тесты, которые падают при изменении внутренней реализации логики и сохранении внешнего интерфейса. При разработке функциональных тестов этого важно избегать.

Приведу пример: если есть API с определенным контрактом (запрос/ответ) — тест не должен падать при изменении реализации этого API с сохранением контракта, то есть при рефакторинге. Тест не должен ничего знать про внутреннюю реализацию API. То же самое касается более сложных бизнес-процессов: тест всегда должен работать с кодом как с черным ящиком, не зная, как процесс устроен внутри.

То есть необходимо соблюдать баланс между юнит тестами и другими видами тестов.

> **Тестировать нужно только публичные методы или АПИ!!!**

Существует 2 школы тестирования:

1. Классическая школа говорит, что нужно использовать *реальные данные*.
2. Лондонская школа - *заглушки*

На данный момент лидирует лондонская школа, тк заглушки облегчают процесс тестируют. И частично решают проблему хрупких тестов. 

> Код теста должен быть простым, иначе можно получить ошибки в тесте и нужны тесты для тестов.

[Мутационное тестирование](https://habr.com/ru/articles/334394/) - это метод тестирования ПО, основанный на всевозможных изменениях исходного кода и проверке реакции на эти изменения набора автоматических тестов. Если тесты после изменения кода успешно выполняются, значит либо код не покрыт тестами, либо написанные тесты неэффективны. Критерий, определяющий эффективность набора автоматических тестов, называется Mutation Score Indicator (MSI).

> **Не переносить на тесты то, что можно решать типами!!!**

## Материалы

1. [JavaScript & Node.js Testing: Best Practices](https://github.com/goldbergyoni/javascript-testing-best-practices/blob/master/readme-ru.md)
2. [Practica.js](https://practica.dev/)
3. [AAA (Arrange-Act-Assert)](https://medium.com/@pjbgf/title-testing-code-ocd-and-the-aaa-pattern-df453975ab80)
4. [TDD (Test Driven Development)](https://www.guru99.com/test-driven-development.html)
5. [Юнит-тестирование для чайников](https://habr.com/ru/post/169381/)